I'm not sure that I'm super happy putting in something that relies on private APIs. Only way I think this would fly is if this script is versioned (via tags) to mirror the android plugin so we can depend on specific versions to ensure current and future correct behavior.

Here's how it works in my build scripts without using private API.

task javadocs(type: Javadoc) {
  source = android.sourceSets.main.allJava
}
afterEvaluate {
  javadocs.classpath += files(android.plugin.runtimeJarList)
}

Yeah that's how I grab it too. You sure that's not a private API? I can't
remember anymore.
On Feb 10, 2014 11:56 PM, "Roman Mazur" [email protected] wrote:

Here's how it works in my build scripts without using private API.

task javadocs(type: Javadoc) {
source = android.sourceSets.main.allJava}afterEvaluate {
javadocs.classpath += files(android.plugin.runtimeJarList)}

Reply to this email directly or view it on GitHubhttps://github.com//pull/13#issuecomment-34732942
.

Well perhaps I'm too confident calling this public API :)
Yet getRuntimeJarList has an explicit public modifier, it might mean something and might not.
Another question is whether android.plugin can be called a public API...

I was mostly posting this Pull Request to get the conversation going.
I realize, and lightly admitted, that the contribution isn't ideal.
I'm fine w/ any solution, but without some sort of contribution, my project is unable to use gradle-mvn-push.gradle.
I found it very odd that my fairly simple library project wouldn't compile, but there seemed to be no one else complaining that this script doesn't work on their library project.

Is the javadoc task required?
Could there be a switch/option to not do it?

It is required. Sonatype will not let you promote a repository to central
without javadoc jars.

It should only fail to compile if you are using Java 8 due to the strict
doclet. I've just been switching to Java 7 when invoking.
On Feb 11, 2014 12:17 AM, "Paul Peavyhouse" [email protected]
wrote:

I was mostly posting this Pull Request to get the conversation going.
I realize, and lightly admitted, that the contribution isn't ideal.
I'm fine w/ any solution, but without some sort of contribution, my
project is unable to use gradle-mvn-push.gradle.
I found it very odd that my fairly simple library project wouldn't
compile, but there seemed to be no one else complaining that this script
doesn't work on their library project.

Is the javadoc task required?
Could there be a switch/option to not do it?

Reply to this email directly or view it on GitHubhttps://github.com//pull/13#issuecomment-34733923
.

Actually javadoc artifact is a Maven Central requirement for jars. I
remember I managed to successfully publish aars without javadocs.

On 11 February 2014 10:17, Paul Peavyhouse [email protected] wrote:

I was mostly posting this Pull Request to get the conversation going.
I realize, and lightly admitted, that the contribution isn't ideal.
I'm fine w/ any solution, but without some sort of contribution, my
project is unable to use gradle-mvn-push.gradle.
I found it very odd that my fairly simple library project wouldn't
compile, but there seemed to be no one else complaining that this script
doesn't work on their library project.

Is the javadoc task required?
Could there be a switch/option to not do it?

Reply to this email directly or view it on GitHubhttps://github.com//pull/13#issuecomment-34733923
.

Best regards,
Roman Mazur

Software engineer at Stanfy (http://stanfy.com.ua)
Skype: roman.mazur.f
LinkedIn: http://ua.linkedin.com/in/romanmazur
Twitter: http://twitter.com/roman_mazur

Do you suspect it is an oversight that it isn't required for aars and that they will eventually make it required?

I believe so. AAR format is still very young. But after releasing 1.0
version of the plugin javadocs might become required for this packaging
type. It seems to be rather plausible.

On 11 February 2014 10:27, Paul Peavyhouse [email protected] wrote:

Do you suspect it is an oversight that it isn't required for aars and that
they will eventually make it required?

Reply to this email directly or view it on GitHubhttps://github.com//pull/13#issuecomment-34734447
.

Best regards,
Roman Mazur

Software engineer at Stanfy (http://stanfy.com.ua)
Skype: roman.mazur.f
LinkedIn: http://ua.linkedin.com/in/romanmazur
Twitter: http://twitter.com/roman_mazur

This seems to choke on external dependencies.

Adding the following statement makes the build successful for me when the library has any external dependencies.

afterEvaluate {
    androidJavadocs.classpath += project.files(android.plugin.getRuntimeJarList().join(File.pathSeparator))
    // add this statement
    androidJavadocs.classpath += project.android.libraryVariants.toList().first().javaCompile.classpath
}

But I'm new to gradle build script, so I don't know this is a proper way to resolve the problem.

i have this problem for android.os
when i wanted to use android.os.Parcelable ,gave me this error

@paulpv @JakeWharton @roman-mazur @tyvsmith @KeithYokoma @yeganehaym your commits merged to https://github.com/Vorlonsoft/GradleMavenPush

For me after updating the the below shown pic for me it worked